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REMARKS 

In the present application claims 1-85 are pending, with claims 1-47, 58-64 and 82-85 
being rejected while claims 48-57 and 65-81 are withdrawn from consideration. In response, 
Applicant presents the following remarks to support the assertion that the above listed claims are 
allowable. 

Amendments to the Specification 

In response to the typing errors noted by the Examiner on pages 2 and 3 of the Office 
Action, changes to the specification have been made. Applicant thanks the Examiner for 
identifying these errors, and believes their correction is now complete. 

The Claim Rejections 

As stated above, the Examiner has rejected all pending claims. More specifically, the 
Examiner has rejected all independent claims of the present application (Claims 1, 44 to 47, 58 
and 82) as being anticipated by Elkin et al. The dependent claims were similarly rejected as 
either anticipated by Elkin et al., or obvious based upon Elkin et al. combined with other 
references. In light of the amendments above, and the following remarks, Applicant submits that 
the above listed claims are now allowable. 

The Present Invention 

As set forth in the claims, the present invention facilitates an end-user's interaction with a 
workflow process stored on a computer, the workflow process being comprised of a plurality of 
interlinked steps. A graphical user interface (GUI) is provided which graphically represents the 
structure of a series of these steps as a plurality of interlinked nodes. It is important to note that 
there is no one fixed path through the workflow and it can be entered at various nodes throughout 
its structure. For example, in the case of a medical scenario as described in the application, 
depending on the thinking of the physician with respect to the patient and the desired level of 
information to assist diagnosis, the entry point could be a node relating to tests associated with 
suspected colorectal cancer, or a node associated with referral information relating to suspected 
colorectal cancer. The intuitive representation of the workflow structure readily allows the end- 
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user to comprehend their position within the workflow regardless of the point of entry and, 
subsequently, to traverse the workflow at a quicker rate. Continuing with the medical example, 
the clinician is advantageously free to jump straight into the point in the workflow relating to 
referral guidelines without having to traverse sections relating to diagnosis, or vice versa. 

In addition to the features above, the GUI facilitates data entry at particular points in the 
workflow process by providing data entry means for entering data at particular nodes. Providing 
this facility at appropriate points within the workflow process improves the speed at which an 
end-user is able to enter data. 

Furthermore, the GUI is provided with pathway means for determining a particular path 
through the workflow process using the data entered by the end-user. Accordingly, by directing 
the end-user in this manner, the speed with which they can navigate through the workflow 
structure is improved. 

Lastly, the graphical representation of the workflow as a 'map' provides the end-user with 
the ability to see, at a glance, at what stage they are in the interactive workflow. In particular the 
end-user can easily see what decisions have been made and what decisions are yet to be made, as 
well as where information has been recorded at previous visited steps in the workflow. 

Elkinetal. fWO 01/0716211. 

As mentioned above, the Examiner's claim rejections were all based upon Elkin et al. A 
review of this reference reveals a system and process that is very different from that described in 
the presently pending claims. Elkin et al. describes a software application for assisting a business 
analyst, designer or developer to define and implement a business process model. As described 
in the introduction, the problem addressed in Elkin et al. is that whilst a business analyst, 
designer or developer may be suitably skilled to define a business process, he or she may lack the 
required computer programming skills to create the software required for an end-user to 
implement that business process once it has been defined. To overcome this problem, Elkin et al. 
describes a series of software tools for use by the business analyst, designer or developer, which 
enables a business process to be defined and implemented without having to do any traditional 
programming (See, Elkin et al., p. 30, lines 4 to 12). 

Elkin et al. utilizes three software tools are used to create and implement business process 
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models, namely (i) a process designer, (ii) a process server and (iii) a process client. The process 
designer is the software tool that allows the business analyst, designer or developer to define a 
process model for their enterprise (see, id. p. 30, lines 6 to 8). This provides the designer with a 
GUI to aid in the development of 'components' and 'resources' (id., p. 1 1, lines 8-10) and to 
allow the definition of process and data flow between the components, without having to do 
traditional programming. Once a business process has been defined, it is deployed to and 
executed in the process server. End-users log into the process server using the process client 
software tool. The process server presents the end-users with a list of their particular task 
assignments. Id. Figure 21, and p. 7, lines 5-6. 

The Independent Claims Are Not Anticipated 

As mentioned above, the Examiner has rejected all independent claims as being 
anticipated by Elkin et al. In support of this rejection, the Examiner has referred specifically to 
Figure 14, p. 33, last paragraph, and p. 4, lines 7-9 of Elkin et al. 

From the discussion above, it is clear that Elkin et al. describes a GUI for use by a 
designer in order to define a workflow process, while the present invention provides a GUI for 
use by an end-user who is currently progressing through, or traversing a workflow process . As 
such, it is submitted that the disclosure in Elkin et al. does not disclose the presently claimed 
invention, and thus cannot anticipate. To clarify these differences Claims 1, 44-47, 58 and 82 
have been amended. 

As set forth above, amended Claim 1 is directed toward a GUI for use by an end-user 
during progression through a workflow process. In addition, Claim 1 now clarifies that an end- 
user is able to traverse the workflow process. 

Further, the pathway has been specified as comprising two or more of the plurality of 
interlinked nodes. Support for these clarifying amendments can be found throughout the 
specification, and specifically at paragraphs [0026], [0029], [0017], [0062] and [0087]. 

It is respectfully submitted that amended Claim 1 is not anticipated by Elkin et al. simply 
because the claimed invention is not disclosed. As an initial point, the GUI of the present 
invention provides an interactive graphical representation of a workflow process to an end-user, 
allowing them to efficiently execute the workflow process, i.e. as the end-user progresses through 
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the workflow process. In contrast, the GUI described in Elkin et al., is for an entirely different 
purpose. Again, the GUI in Figure 14 of Elkin et al. is used by a designer , and assists the 
designer to define or create a workflow process . The designer in Elkin et al. is not an end-user. 
As described on page 7, lines 5-6, and page 47, the end-user in Elkin et al. interacts with the 
'process client', which is shown in Figure 21. Therefore, the GUI of Elkin et al. does not interact 
with an end-user as required by amended Claim 1. Further, the designer does not, progress 
through, or traverse the workflow process. Therefore, the GUI in Figure 14 of Elkin et al. does 
not interact with an end-user that is progressing through a workflow process or traversing a 
workflow process, as required by amended Claim 1 . 

In addition to the points raised above, a very different end-user experience is described in 
Elkin et al. See, Elkin et al. "Process Clients 600" p. 47, lines 1-17. The end-user logs onto a 
process server to 'view, fetch and execute tasks'. The process server in Elkin et al. merely 
presents the end-user with a list of tasks in the form of a 'task list' (as shown in Figure 21) based 
on the roles and attributes of the logged-on user as mentioned above. This is clearly different 
from the graphical user interface set forth in Claim 1 of the present application. 

Lastly, there is no disclosure in Elkin et al. of a means for graphically representing a 
resultant pathway through a workflow process, wherein the pathway comprises two or more of a 
plurality of interlinked nodes. This also contributes to the very different end user experience. 

Based upon the differences discussed above, Applicant asserts that the invention of 
amended Claim 1 is not anticipated by or obvious in light of Elkin et al. Elkin et al. merely 
presents the end-user with a list of tasks to be performed. Conversely, the presently claimed 
invention provides a useful tool for assisting an end-user to navigate, or traverse through what is 
often a complicated workflow process and information resource, which may include several 
different pathways to choose from. The end-user is able to jump-in at an appropriate point of the 
workflow without having physically to traverse all the nodes of the map as has been mentioned 
before. 

While Claim 1 has been discussed in detail, these remarks are equally applicable to the 
remaining independent claims. Generally, independent claims 44-47, 58 and 82 are all submitted 
to be allowable for the same reasons. 
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Independent Claim 58 

While the above comments are applicable to Claim 58, further remarks are appropriate. 

Specifically, Claim 58 includes the ability to edit data at the nodes. This feature is not taught by 

Elkin et al. 

In rejecting Claim 58 the Examiner has referred specifically to the final paragraph on 
page 33 of Elkin et al. This paragraph refers to Figure 14, which shows the user interface of the 
process designer GUI in Elkin et al. as discussed above. 

Again, the process designer GUI in Figure 14 of Elkin et al. is for a designer to use to 
define or create a workflow process. Hence, the GUI in Figure 14 of Elkin et al. does not interact 
with an end-user during progression through a workflow process. 

Likewise, the end-user in Elkin et al. is not able to edit the GUI shown in Figure 14. As 
such, Elkin et al. does not disclose a GUI having editing means for enabling an end-user to edit a 
plurality of interlinked nodes, as required by amended Claim 58. For this additional reason, 
Applicant submits that Claim 58 is not anticipated or made obvious by Elkin et al. 

Independent Claim 82 

The Examiner also rejected Claim 82 as being anticipated by Elkin et al. In addition to 
the reasons discussed above, additional reasons exist to assert that Claim 82 is allowable. 
The invention defined in Claim 82 generally relates to a method of constructing a GUI. As set 
forth in the claim itself, the method involves: 

1) collating content regarding a workflow; 

2) recording that content in a database as a series of steps of a hierarchically structured 
workflow; and 

3) generating a graphical representation of the hierarchical workflow structure from the content 
recorded in the database, which can be used to guide an end-user progressively through the 
workflow. 

As already discussed above, the GUI described in Elkin et al. is used by a designer to 
create or define a workflow without the need for programming skills. This is achieved by 
providing the designer with a number of 'building blocks' which are graphical objects that each 
represent a component of a workflow process. The building blocks have predetermined 
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attributes depending on the task that they are to represent. To define a workflow process using 
the GUI, the designer first selects a number of relevant building blocks and positions these on the 
page, as shown in Figure 14 of Elkin et al. (see also, p. 35, line 8 to p. 44, line 4). The building 
blocks are then 'wired' together to create a graphical representation of the defined workflow. 
The attributes of the building blocks may then be changed according to the particular 
requirements. See Elkin et al, p. 4, lines 7-19. 

In contrast, the first stage in constructing a GUI according to pending Claim 82 is to 
populate a database with content relating to a workflow. Once the database has been populated 
with content, the graphical representation of the workflow is generated from that content. By 
generating the graphical representation from a set of data, as opposed to fitting data to a graphical 
representation, the GUI created by the present invention can advantageously adapt to 
accommodate additional or changing content, or changes in the hierarchical structure of the 
workflow process. As described in paragraph [0050] of the present application, whereas all prior 
art applications (Elkin et al. included) have been built as software applications first and foremost, 
the present invention is advantageously designed and built around the content of the workflow, 
thereby facilitating the later addition of software applications to the content. 

Accordingly, it is submitted that amended Claim 82 is allowable as Elkin et al. does not 
disclose the collation of content and subsequent recordal in a database as a hierarchically 
structured workflow prior to the generation of a graphical representation of the workflow. In 
addition and as discussed in detail above, Elkin et al. does not disclose a graphical representation 
of a workflow comprising a plurality of interlinked nodes that can be used to guide an end-user 
through a workflow. 

The Dependent Claims 

Regarding the rejection of the dependent claims, Applicant generally asserts that the 
positions taken by the Examiner are appropriate. In view of these claims being dependent on 
allowable independent claims, further discussion is unnecessary. 

Claims 4, 1 1-19, 21, 24-26, 31-34, 36-41, 43, and 59 to 62 have been amended in 
accordance with the amendments made to the independent claims. Specifically, the term user has 
been replaced by the term end-user to provide consistency and clarity. Further Claims 41 and 42 
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have been amended in accordance with amended Claim 1, by replacing the term path with 



New dependent Claim 86 has been included to claim the feature of the editing means 
being restricted by permissions as described in paragraph [0078] of the present application. 
Conclusion 

In light of the above amendments and arguments Applicant asserts that the present 
invention, as claimed, is allowable and requests favourable consideration by the Examiner. 

In the event a telephone conference would expedite the prosecution of this application, 
the Examiner may reach the undersigned at 612-607-7387. If any additional fees are due in 
connection with this Amendment and Response, the Commissioner is hereby authorized to 
charge such fees, including extension of time fees, to Deposit Account No. 50-1901 (Ref. No. 
22557-3001). 



pathway. 
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